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HOSTNAME SERVER 


STATUS OF THIS MEMO 


This RFC is the official specification of the Hostname Server 


Protocol. This edition of the specification includes minor revisions 
to RFC 811 which brings it up to date. Distribution of this memo is 
unlimited. 

INTRODUCTION 


The NIC Internet Hostname Server is a TCP-based host information 
program and protocol running on the SRI-NIC machine. It is one of a 
series of internet name services maintained by the DDN Network 
Information Center (NIC) at SRI International on behalf of the 
Defense Communications Agency (DCA). The function of this particular 
server is to deliver machine-readable name/address information 
describing networks, gateways, hosts, and eventually domains, within 
the internet environment. As currently implemented, the server 
provides the information outlined in the DoD Internet Host Table 
Specification [See RFC-952]. For a discussion of future developments 
see also RFC-921 concerning the Domain Name System. 


PROTOCOL 


To access this server from a program, establish a TCP connection to 
port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or 
10.0.0.51). Send the information request (a single line), and read 
the resulting response. The connection is closed by the server upon 
completion of the response, so only one request can be made for each 
connection. 

QUERY/RESPONSE FORMAT 
The name server accepts simple text query requests of the form 

<command key> <argument(s)> [<options>] 

where square brackets ("[]") indicate an optional field. The command 
key is a keyword indicating the nature of the request. The defined 
keys are explained below. 


The response, on the other hand, is of the form 


<response key> : <rest of response> 
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where <response key> is a keyword indicating the nature of the 
response, and the rest of the response is interpreted in the context 
of the key. 


NOTE: Care should be taken to interpret the nature of the reply 
(e.g, single record or multiple record), so that no confusion about 
the state of the reply results. An "ALL" request will likely return 
several hundred or more records of all types, whereas "HNAME" or 
"HADDR" will usually return one HOST record. 

COMMAND/RESPONSE KEYS 


The currently defined command keywords are listed below. NOTE: 
Because the server and the features available will evolve with time, 
the HELP command should be used to obtain the most recent summary of 
implemented features, changes, or new commands. 

Keyword Response 


HELP This information. 


VERSION "VERSION: <string>" where <string> will be different for 
each version of the host table. 


HNAME <hostname> 
One or more matching host table entries. 


HADDR <hostaddr> 
One or more matching host table entries. 


ALL The entire host table. 

ALL-OLD The entire host table without domain style names. 
DOMAINS The entire top-level domain table (domains only). 
ALL-DOM Both the entire domain table and the host table. 
ALL-INGWAY 


All known gateways in TENEX/TOPS-20 INTERNET.GATEWAYS 
format. 


Remember that the server accepts only a single command line and 
returns only a single response before closing the connection. HNAME 
and HADDR are useful for looking up a specific host by name or 
address; VERSION can be used by automated processes to see whether a 
"new" version of the host table exists without having to transfer the 
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whole table. Note, however, that the returned version string is only 
guaranteed to be unique to each version, and nothing should currently 
be assumed about its format. 


Response Keys: 


ERR entry not found, nature of error follows 
NET entry found, rest of entry follows 
GATEWAY entry found, rest of entry follows 

HOST entry found, rest of entry follows 
DOMAIN entry found, rest of entry follows 

BEGIN followed by multiple entries 

END done with BEGIN block of entries 


More keywords will be added as new needs are recognized. A more 
detailed description of the allowed requests/responses follows. 


QUERY/RESPONSE EXAMPLES 


1. HNAME Query - Given a name, find the entry or entries that match 
the name. For example: 


HNAME SRI-NIC.ARPA <CRLF> 


where <CRLF> is a carriage return/ linefeed, and ’SRI-NIC.ARPA’ 
is a host name 


The likely response is: 

HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA, SRI-NIC,NIC 
DEC-2060 : TOPS20 : TCP/TELNET, TCP/SMTP, TCP/TIME, TCP/FTP, 
TCP/ECHO, ICMP 


A response may stretch across more than one line. Continuation 
lines always begin with at least one space. 


2. HADDR Query - Given an internet address (as specified in RFC 796) 
find the entry or entries that match that address. For example: 


HADDR 26.0.0.73 <CRLF> 


where <CRLF> is a carriage return/ linefeed, and ’26.0.0.73’ is 
a host address. 


The likely response is the same as for the previous HNAME request. 


Harrenstien & Stahl & Feinler [Page 3] 


RFC 953 October 1985 
Hostname Server 


3. ALL Query - Deliver the entire internet host table in a 
machine-readable form. For example: 


ALL <CRLF> ;where <CRLF> is a carriage return/linefeed 


The likely response is the keyword ’BEGIN’ followed by a colon 
':', followed by the entire internet host table in the format 
specified in RFC-952, followed by ’END:’. 


ERROR HANDLING 


ERR Reply - may occur on any query, and should be permitted in any 
access program using the name server. Errors are of the form 


ERR : <code> : <string> 
as in 
ERR : NAMNFD : Name not found 


The error code is a unique descriptor, limited to 8 characters in 
length for any given error. It may be used by the access program to 
identify the error and, in some cases, to handle it automatically. 
The string is an accompanying message for a given error for that case 
where the access program simply logs the error message. Current 
codes and their associated interpretations are 


NAMNFD Name not found; name not in table 

ADRNFD Address not found; address not in table 

ILLCOM Illegal command; command key not recognized 

IMPSYS Temporary system failure, try again later 
REFERENCES 


1. Harrenstien, K., Stahl, M., and Feinler, E., "Official DoD 
Internet Host Table Specification," RFC-952, DDN Network 
Information Center, SRI International, October 1985. 


2. Pickens, J., Feinler, E., and Mathis, J., "The NIC Name Server," A 
Datagram-based Information Utility, RFC-756, Network Information 
Center, SRI International, July 1979. 


3. Postel, J., "Address Mappings," RFC-796, Information Sciences 
Institute, University of Southern California, Marina del Rey, 
September 1981. 


4. Postel, J., "Domain Name System Implementation Schedule", RFC-921, 


Information Sciences Institute, University of Southern California, 
Marina del Rey, October 1984. 


Harrenstien & Stahl & Feinler [Page 4] 


RFC 953 October 1985 
Hostname Server 


Harrenstien & Stahl & Feinler [Page 5] 


